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COMMUNICATION SYSTEM AND METHOD PROVIDING A MODE SELECTION 
5 PROCEDURE 

FIELD AND BACKGROUND OF THE INVENTION 

10 The present invention relates to a communication system adapted 
to perform a mode selection by selecting or negotiating the 
mode to be used. Furthermore, the invention relates to a method 
to be performed in such a communication system, and to a 
network element capable of mode selection. 

15 

Advancements in digital communication techniques have permitted 
increased data transmission rates and introduction of new types 
of communication services. When digital communication 
techniques are utilized, data which is to be communicated is 

20 digitized into digital form, and sometimes formatted into data 
packets. The data packets are communicated, either 
individually, or in groups, to a destination. Once received at 
the destination, the packets are concatenated together to 
recreate the informational content of the data of which the 

25 data packets are formed. 

Radio communication systems are exemplary of communication 
systems which have benefited from advancements in communication 
technologies and in which digital communication techniques are 

30 increasingly utilized. A cellular communication system is an 
exemplary radio communication system. And, various standards 
have been promulgated pursuant to which different types of 
cellular communication systems have been constructed. 
Additional standard specifications continue to be promulgated 

35 relating both to improvements to existing cellular 
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communication systems as well as new constructions of cellular 
communication systems. Standards relating to so-called, third- 
generation, cellular communication systems are presently being 
promulgated- Standards relating to the 3G (third generation) 
5 GSM/EDGE (Global System for Mobile Communications /Enhanced Data 
for Global Evolution) system, for instance are being 
promulgated. 

In packet switched communications, data to be communicated is 
10 formatted into packets, and the data packets ar. communicated 
at discrete intervals. Because the data can be cor-jnunicated at 
discrete intervals, the communication resources, such as the 
bandwidth available upon the radio links formed between mobile 
stations and network infrastructure of the system, can be 
15 utilized more efficiently. 

Packet-switched communications in which communications are 
effectuated by the communication of data packets include voice 
communications. When the data packets are formatted pursuant to 

20 IP (Internet Protocol) protocols, the resultant communication 
service is sometimes referred to as VoIP (Voice over Internet 
Protocol) . As with other types of voice communication services, 
VoIP is time sensitive in that the data forming the VoIP data 
packets must be timely communicated to maintain an acceptable 

25 communication quality level . 

The data packets are typically formatted pursuant to 
conventional standards. Each data packet is typically formatted 
to include a header portion and a payload portion. The payload 

30 portion is formed of the data which is to be communicated to 
effectuate the communication service. In a VoIP service, the 
voice data is contained in the payload portion of the data 
packet. And, the header portion includes information needed to 
route the data to a desired receiving station and to identify 

35 the order of the data packet amongst a group of data packets. A 
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conventional data packet includes an RTP (Realtime Transport 
Protocol) header field, a UDP field, and an IP (Internet 
Protocol) field. The RTP field includes a time stamp value 
which specifies the time when the voice data of the packet is 
5 created. The time stamp is used at a receiving station to 

correct for delay fluctuation introduced during communication 
of the data packet. The RTP field also includes a sequence 
number. The sequence number is used at a receiving station to 
detect packet loss and mis-sequencing of data packets. Values 
10 of the UDP and IP fields are generally of constant values for 
data packets generated within a single communication session 
and identify the identities of the sending and receiving 
stations . 

15 Communication systems are usually bandwidth-constrained. That 
is to say, the bandwidth available to define communication 
channels and allocated for use in a communication system 
typicaTly limit the communication capacity of the communication 
system. The communication capacity of the communication system 

20 can be increased only when the bandwidth allocated to the 
communication system is used more efficiently. Constraints 
placed upon radio communication systems are oftentimes 
particularly acute as the bandwidth allocated to a radio 
communication system is typically limited to a frequency region 

25 of the electromagnetic spectrum. 

A problem associated with the use of packet-formatted data is 
the relatively high percentage of the bandwidth consumed by the 
communication of the header portions of all of the data 
30 packets. Communication of the voice information pursuant to a 
VoIP communication service is much less efficient than it 
otherwise would be if the header portions of the data packets 
are removed. 
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To increase the efficiency of use of the bandwidth allocated 
upon the radio link, proposals have been set forth to provide 
manners by which to remove the header portions of the data 
packets prior to their communication upon the radio links 
5 formed between mobile stations and the network infrastructure 
of the communication system. 

More generally, communication networks transfer information 
such as user voice traffic or the like, on a packet-switched 

10 and/or circuit-switched basis using modes which may be 

commanded by the system or negotiated between the involved 
network elements such as end user equipments. As an example, in 
evolved networks such as UMTS (Universal Mobile 
Telecommunication System) systems, additional functions and 

15 services can be incorporated. For instance, novel multimedia 
services such as multimedia messaging services MMS are 
supported within the system which services are IP (Internet 
Protocol) -based services. Packet-based (e.g. IP-based) service 
sessions such as multimedia service sessions may be controlled 

20 by a specific protocol. As an example, the Session Initiation 

Protocol (SIP) represents a protocol which may be used e.g. for 
call and connection establishment as well as for transport of 
endpoint capability information. Such capability information 
may e.g. relate to voice and multimedia codecs supported by the 

25 end terminals. 

The functionality and services of such multimedia service 
systems will be mapped onto the existing network system 
functions, e.g. of UMTS type. As an example, the system 
30 services may be mapped to the PDP contexts and radio 

signalling, as well as to existing packet-switched core network 
elements and interfaces, e.g. of UMTS type. Hence, there is a 
problem of multimedia (e.g. IP multimedia) and network layer 
(e.g. GPRS layer) interactions and mapping. 

35 
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As an example, in case of VoIP calls (voice over IP-based 
connection, i.e. Internet telephony), the radio access network 
such as GERAN ("GSM/Edge Radio Access Network") and UTRAN (UMTS 
Terrestrial Radio Access Network) , may be informed on the type 
5 of application for deciding on the header adaptation method to 
be used for e.g. a particular PDP context. As an example, two 
different header adaptation schemes available for selection can 
for example be "header compression" and "header 
stripping/removal" . The header stripping/removal mode may be 

10 used for speech-only traffic where e.g. optimised speech 

transport is required for instance for integrated lower-end 
terminal devices. A header compression mode may be utilised 
e.g. for more general IP multimedia traffic including voice 
application operation on an external device such as a laptop 

15 computer connected to a UMTS phone. 

When an inappropriate mode such as inappropriate protocol mode, 
header "adaptation mode or radio access bearer mode should be 
selected, problems in incorrect message transmission may occur. 

20 

SUMMARY OF THE INVENTION 

The invention provides a method and system as defined in anyone 
25 of the claims . 

In more detail, a communication system, and/or a method to be 
performed in a communication system, comprises at least one. 
first network element connectable to a second network element 

30 via one or more packet-based networks. At least one of the 
first and second network elements provide two or more 
selectable modes for communicating with another network 
element. A mode selection procedure is performed (e.g. by one 
or both of the network elements, or by a third network element 

35 connected to the first and second network elements) , for 
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selecting the same mode for bidirectional communication between 
the network elements. The selectable modes preferably are 
different codec types, or may be conversion modes of other 
type, or radio interface protocol types or channel-coding 
5 schemes etc. 

The first and/or second network elements may be portable 
terminal equipments. The third network element preferably is a 
support node or support function. 

10 

In a preferred embodiment, a protocol mainly used for other 
purposes but also capable of providing a messaging service, 
preferably an IP-based multimedia messaging service, is used 
for sending information on supported or selected modes to and 
15 from the network elements. The protocol may be the Session 
Initiation Protocol (SIP) . SIP is a multimedia session 
establishment & control protocol, i.e. a control protocol for 
realtime multimedia . 

20 Preferably, the network or networks connecting the first and 
second network elements is/are UMTS-based network. 

In one embodiment, the first network element may send 
information on one or more modes supported by the first network 

25 element to the third network element which performs the 

selection procedure and sends information on only one or more 
than one but not all supported modes to the second network 
element which sends an acknowledgment message to the third 
network element confirming the support of the selected, or one 

30 of the selected modes, the third network element sending a 

message to the first network element informing the latter on 
the selected mode. This is one difference between a preferred 
embodiment of the invention and the usual SIP operation. 
Usually there is no negotiation between the used codecs etc. 

35 but both elements include information on their own capabilities 
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in the SIP messages. Here, a selection and a specific usage of 
the information fields etc. is proposed. 

In another embodiment, the first network element may send 
5 information on one or more modes supported by the first network 
element to the third network element which requests the second 
network element to send information on the supported modes, the 
second network element returning a list of supported modes to 
the third network element whereupon the third network element 
10 performs the selection procedure and sends messages to the 
first and second network elements informing these network 
elements on the selected mode. 

In a further embodiment, the first network element performs the 
15 selection procedure when initiating a connection to the second 
network element, and sends information on one mode supported by 
the first network element to the second network element. The 
second ^network element, when supporting the mode, returns an 
acknowledgment message, or, when not supporting the mode, 
20 returns a message indicating another mode supported by the 

second network element, to the first network element. The first 
network element selects this mode for further communication 
when supporting it, or, when the first network element does not 
support the mode indicated by the second network element 
25 repeats the steps a) to d) selecting another mode. 

In a further embodiment, the first network element, when 
initiating a connection to the second network element, sends 
information on all modes supported by the first network element 
30 to the second network element. The second network element 
performs the selection procedure and returns a message 
indicating the selected mode to the first network element, 
the first and second network elements selecting the indicated 
mode for further communication. 

35 

7 

BNSDOCID: <WO 0215627A1_1_> 



WO 02/15627 



PCT/EP01/09292 



The first: network element and/or second network element and/or 
third network element preferably send information on the 
selected mode to a radio network control means. The information 
on the selected protocol mode may e.g. be sent as part of a 
5 negotiation procedure related to packet data convergence 
protocol, or in an Activate PDP Context message. The 
information on the selected mode preferably contains an 
additional flag indicating the application type. It is possible 
to send only the application type and no other information. 

10 

The information on the selected mode preferably contains 
additional information on. the header processing such as header 
compression or header stripping/removal. 

15 Generally, in accordance with the present invention, a 
selection procedure is provided for performing a mode 
selection, preferably when establishing a connection between 
two network elements. This mode selection such as protocol 
selection is ensuring that the bi-directional communication 

20 between the network elements is performed in a defined manner 
such as use of the same mode in uplink and downlink direction. 

As an example, such a mode selection is able to ensure that 
e.g. the radio access bearers in an UMTS network use and 

25 support the same codec type (e.g. AMR (Adaptive Multi-Rate) , 

GSM FR (Full Rate), GSM EFR (Enhanced Full Rate), etc.) at the 
same time, and use the same, i.e. only one, codec type in 
uplink and downlink directions. In some cases such as AMR, 
there might otherwise be provided different codec modes in 

30 uplink and downlink direction. The codec information may be 

used to select the appropriate radio interface protocol modes 
including an appropriate channel coding scheme for voice 
traffic. 
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The use of the same codec in both directions guarantees that 
the channel coding for the corresponding radio bearer of a PDP 
(Packet Data Protocol) context is appropriately and correctly 
selected so as to be the same in both directions. As at least 
5 one PDP context is necessary for carrying the voice traffic, an 
appropriate radio bearer is selected so that UMTS IP telephony 
can be performed (VoIP) without problems - 

An advantage of the invention is the possibility to enable e.g. 

10 SIP operation on top of an UMTS radio access network 

architecture and bearers. Apart from the fact that the new 
information on selected mode and application type provided to 
the radio access network is already a sort of change of the 
existing network architecture, no other changes of existing 

15 radio access networks such as UTRAN or GERAN for any actual or 
future definition such as 3GPP Release 2000 are necessary for 
solving the above mentioned problems. The invention therefore 
provides a solution for IP telephony on UMTS. 

20 The solution according to the invention can be implemented „ as a 
proprietary mechanism or function, or can be a standardised 
mechanism or function. 

In accordance with a further aspect of the invention, a network 
25 element is provided, preferably to be used in a method or 

communication system as described above, the network element 
being adapted to perform a selection procedure for selecting 
one of several modes supported by this or another network.. , 
element. The modes may be different , conversion modes, in 
30 particular coding/decoding modes. 

According to another aspect, the invention may provide a manner 
which facilitates signaling of whether the header portions of 
the data packets are to be removed pursuant to effectuation of 
35 a communication service. Signaling is preferably provided 
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between the mobile station and the network infrastructure to 
identify when header portions of the data packets are to be 
removed pursuant to effectuation of a communication session. 
The invention provides signaling of such information and 
5 adequately defines the manner by which to signal whether the 

header portions of the data packets are to be removed- A QoS IE 
can be used for such a purpose, representing an example on how 
additional information on the selected protocol can be 
expressed. This feature of header stripping/removal can also be 
10 used independent of the other features mentioned in the 
description or claims. 

In an embodiment, the invention provides an apparatus and 
method for initiation of header-portion removal in a radio 

15 communication system having a mobile station operable to 

communicate packet-switched data with a correspondent node by 
way of network infrastructure, the packet-switched data 
formatted into data packets, the data packets having header 
portions and payload portions. The header-portion removal 

20 facilites the communication of the packet-switched data upon a 
radio link formed between the mobile station and the network 
infrastructure . 

A means or function, e.g. QoS (Quality of Service) information 
25 element (IE) message generator, is coupled to receive 

indications of selection of a preference to communicate data 
without the header portions upon the radio link. A QoS 
information element message containing an indication of the 
preference is generated. 

30 

Further aspects, advantages and details of the invention will 
be described by referring to the attached drawings which 
disclose preferred embodiments of the invention. 

35 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows the basic structure of a first embodiment of 
the present invention; 

5 

Fig. 2 illustrates a second embodiment of the invention; 
Fig. 3 shows another embodiment of the invention; 

10 Fig. 4 illustrates a further embodiment of the invention ; 

Fig. 5 illustrates a functional block diagram of a 
communication system in which an embodiment of the present 
invention is operable; 

15 

Fig. 6 illustrates a logical layer representation of 
portions of the communication system shown in Fig. 5, here 
representing packet header removal of packet headers from RTP 
(Real-Time Transport Protocol) -formatted data packets 
20 communicated during operation of the communication system; 

Fig. 7 also illustrates a logical layer representation of 
portions of the communication system shown in Fig. 5, here 
representing header generation by which packet header 
25 information is added to data packets communicated during 

operation of the communication system; 

Fig. 8 illustrates a message sequence diagram illustrating 
messages generated during operation of the communication system 
30 shown in Fig. 5, including a message containing a QoS (quality 
of service) information element (IE) of an embodiment of the 
present invention; and 

Fig. 9 illustrates representation of the QoS information 
35 element including indicia indicating a preference of a header 
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adaptation mechanism to be utilized pursuant to a communication 
session. 

5 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION 

Before describing some embodiments of the invention in more 
detail, several general aspects and features of the invention 
will be discussed. In connection set-up, some protocols such as 

10 the call establishment procedures of SIP (Session Initiation 
Protocol) allow negotiation and usage of several codecs from 
end-to-end, that is between the call originating element and 
the call terminating element. Further, such protocols may also 
allow the use of different codecs in uplink and downlink 

15 directions. Due to the selection procedure performed in 
accordance with a preferred aspect of the invention, IP 
telephony applications in networks such as UMTS of third 
generation type can be used on top of the UMTS radio access 
networks (RANs) without interfering with the functionality of 

20 the system and with minimum changes of the system. Hence, 
correct functioning can be ensured also in such cases. 

When using for instance SIP, the caller may send a set of 
supported codecs to the callee or to a third network element- 

25 The callee may also send a set of supported codecs to the 

caller or to the third network element. After the call-setup, 
when sending VoIP packets, the invention may be used to 
guarantee that the caller uses one of the codecs supported by 
the callee and the callee uses one of the codecs supported by 

30 the caller, and that these used codecs are the same for the 
callee and the caller. Otherwise, when not performing a mode 
selection procedure for selecting e.g. only one and the same 
codec for the bidirectional communication, the sender might 
dynamically select a codec from the set of codecs supported by 

35 the recipient when sending data to the latter so that different 
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codecs might eventually be used. Furthermore, the used codec 
might be different in different directions. 

In accordance with preferred implementations of the invention, 
5 several alternatives are disclosed. According to one aspect, a 
terminal equipment (network element), e.g. a UMTS phone, or the 
network, e.g. the UMTS network, functions so as to ensure that 
always only one codec type is used in each direction, and 
further that this codec type is the same in both directions. 
10 This may be achieved in one or both terminal equipments such as 
UMTS terminals by mandating support for specific codec (s) in 
all cases and/or by defining that only one codec can be 
announced to the other endpoint as supported codec. 

15 Furthermore, the behaviour of the callee is defined and adapted 
in such a manner that the call terminating equipment selects, 
if possible, the same codec as the one announced by the call 
originating equipment. In case of failure of the call 
terminating equipment in selecting the same codec as the one 

20 announced by the call originating equipment, the call 

terminating equipment is preferably adapted to select a codec 
which is mandatory in systems of the third generation (3G 
systems) , and to announce this codec to the call originating 
equipment. The call originating equipment will support the 

25 announced codec as it is a mandatory one, and is adapted to 

assume at this point that the call terminating equipment wi±j. 
use the same codec also in sending data, and will therefore 
adjust its behaviour accordingly. 

30 In accordance with another alternative embodiment of the 

invention, a further solution is provided. In the network such 
as the UMTS network, a control means (third network element) 
will decide on the codec to be used and will handle the 
selection procedure and the necessary messages to be sent to 

35 the call originating and terminating equipments. This control 
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means may e.g. be the CSCF (Call State Control Function) of the 
network and/or may e.g. be the proxy CSCF in the visited 
network such as PLMN (Public Land Mobile Network) in case of a 
roaming subscriber , and/or the home CSCF in the home network 
5 e.g. PLMN of the subscriber. 

The control means can render the decision on the codec to be 
used by both the call originating and terminating equipments. 
In preferred implementation, the codecs supported by the call 

10 originating equipment are included in a specific message such 
as the Invite message of SIP. After receiving the Invite 
message, the control means such as CSCF can select one of the 
codecs, i.e. perform the mode selection procedure, and can 
modify the Invite message so as to include only the selected 

15 codec before forwarding the Invite message to the call 

terminating equipment. The call terminating equipment is 
adapted to acknowledge receipt the Invite message by sending an 
acknowledgement message such as 200 OK message of SIP, only if 
it supports the single codec indicated in the Invite message as 

20 selected by the control means. It is possible to send an 

acknowledgement message also in the negative case, e.g., giving 
negative acknowledge or including the supported codecs by the 
call terminating equipment.) 

25 The selection procedure performed in the control means such as 
CSCF may be based e.g. on the operator preferences. As an 
example, when the operator prefers to use AMR, the selection 
procedure is adapted to select AMR from a set including FR, HR 
and AMR. Another example is a case when a transcoder pool is 

30 used. In such a case, the operator may optimise the usage of 

the transcoders. In the latter case, the decision and selection 
is preferably made in a control means of the visited network, 
that is in a visited network element such as e.g. in the proxy 
CSCF. 

35 
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Furthermore, location information of the user may be taken into 
account when deciding on the codec to be used. For example, if 
the base station subsystems (BSSs) in different parts of the 
network/country are e.g. based on different product releases 
5 and for this or other reasons prefer different codecs, or for 
reasons of transcoder pool optimisation, the codec selection 
procedure may be adapted to take account of such parameters. 

A further alternative approach implemented in another 
10 embodiment of the invention is the selection of the codec by a 
control network element such as CSCF after having received 
information on all codecs supported by the call originating 
equipment (e.g. in an Invite message) and on all codecs 
supported by the call terminating equipment (e.g. in the 200 OK 
15 message of SIP). After having received both the messages, the 
control means knows both codec sets supported by the call 
originating equipment as well as by the call terminating 
equipment. The control means then performs the mode selection 
step by selecting one codec supported by both call originating 
20 and terminating equipments either by arbitrarily or by 

reference to a priority list ranking the codecs according to 
the priority assigned by e.g. the network operator or service 
provider . 

25 After selecting the codec to be used by both call originating 
and terminating equipments, the selected codec is sent to the 
call originating equipment in a further message such as a 200 
OK message of SIP generated by modifying the 200 OK message 
received from the call terminating equipment, and to the call 

30 terminating equipment in another message such as a ACK message 
of SIP. 

When the codec to be used has been selected, one or more 
network elements, in particular control elements such as the 
35 radio network controllers or base station subsystems 
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controlling the radio access to the call originating and/or 
call terminating equipment have to be informed on the selected 
codec. This informing of the network control elements can be 
performed in several alternative ways which are listed below in 
5 the preferred order. 

1. ) The call originating and/or terminating equipment such 
as a mobile station (MS) sends information on the selected 
codec to the radio access controller (e.g. RNC, Radio Network 

10 Controller) as part of the PDCP (Packet Data Convergence 

Protocol) negotiation. The messages sent to the control element 
informing the same about the selected codec may additionally 
include a separate flag or other indication to indicate the 
application type, and/or whether to use header compression or 

15 header stripping/removal for this particular PDP context. 

2. ) As an alternative, the call originating and/or 
terminating equipment sends the information on the selected 
codec to the serving node such as SGSN (Serving GPRS Support 

20 Node) . The serving node forwards the information on the 

selected codec to the control element such as RNC in the RAB 
(Radio Access Bearer) establishment request message. The 
transmitted message (s) may additionally include further 
information such as a flag to indicate the application type, 

25 and/or whether to use header compression or stripping/removal 
for a particular PDP context. 

3. ) The call state controlling means such as CSCF may send 
information on the selected codec to the radio access control 

30 means such as RNC (e.g. in the following manner: CSCF -> GGSN 
(Gateway GPRS Support Node), GGSN -> SGSN, SGSN -> RNC). As 
already stated above, the messages may also include a separate 
indication such as a flag to indicate the application type, 
and/or whether to use header compression or stripping/removal 

35 for the particular PDP context. 
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When an application type indication (e.g. application type 
flag) is included, the information on the application type is 
transmitted from the call originating or terminating equipment 
5 (e.g. Mobile Station MS) or from the call control means (e.g. 
CSCF) because these entities are, in an UMTS network, the only 
entities having enough information about the services and 
applications running on top of the PDP contexts. The header 
compression is preferably set as the default operation if the 
10 application type is not known or indicated in the message. The 
header stripping/removal is preferably used for optimised 
speech transmission when only voice traffic is carried in the 
PDP context. 

The necessary application information is preferably received 
through internal application programming interfaces (APIs) of 
the call originating and/or terminating equipments (the 
internal APIs being arranged between the 

applications/services), the SIP layer and the UMTS/GPRS layers. 
Header stripping/removal is preferably used only in the case of 
an integrated UMTS SIP terminal. It may also be provided from a 
laptop computer to a UMTS phone in a case where the terminal 
equipment (TE) and the call originating and/or terminating 
equipments are separate devices. The application type 
indication such as a flag may for example have the following 
explicit values: "header compression", or "header 
stripping/removal", or "application type" (e.g. value: voice) 
which indicates that stripping/removal is to be used. 

In the following, details of a first embodiment will, be 
described with reference tio Fig. 1. Fig. 1 shows a terminal 
network element 1 which is termed "UE (User Equipment) Caller" 
and requests the establishment of a connection' to another 
network element 3. The network element 3 thus represents a call 
terminating equipment and is termed "UE Callee". The network 
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comprises a further network element 2 which is a connection 
control element and is implemented as, or provides, a call 
state control function (CSCF) . When the network element 1 such 
as a MS (Mobile Station) desires to establish a connection to 
5 the terminal network element 3, it is adapted to send, in this 
embodiment, a message to the CSCF 2 informing the latter on the 
desire to establish a connection to the terminal equipment 
element 3 which message contains information on all codecs 
supported by the network element 1, i^e. the call originating 
10 equipment. This message may be an Invite message of the 
connection protocol, preferably SIP . This Invite message 
contains a list of codecs supported by network element 1. 

The CSCF element 2 is adapted to perform a mode selection 
15 procedure which, in this embodiment is a codec selection 

procedure 4 selecting one of the cc...cs supported by equipment 
1. This codec selection 4 may be based on preference or 
priority parameters contained in CSCF 2, or may be dependent 
from the type of application desired by equipment 1 such as 
20 pure data transmission, pure voice over IP transmission, and 
the like. 

After performing the codec selection procedure 4, the CSCF 2 
further transmits the Invite message to the user equipment 3, 

25 the message now only including the codec selected by the codec 
selection procedure 4, The user equipment 3 which may likewise 
be a mobile station or a stationary equipment, performs an 
internal check whether it supports the codec indicated in the 
received Invite message. If yes, the user equipment 3 returns 

30 an acknowledgement message to the CSCF 2 (preferably a 200 OK 
message in SIP) which message repeats the selected codec for 
confirmation of its support by user equipment 3. The CSCF 2 
transmits this acknowledgement message to the user equipment 1 
(200 OK (selected codec)) in SIP. 

35 
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When receiving this message, the user equipment 1 is adapted to 
use only this indicated codec for uplink and downlink links. In 
a similar manner, user equipment 3 is adapted to use only the 
selected codec for uplink and downlink traffic, i.e. for radio 
5 access between user equipment 3 and the radio access 

controlling means such as RCP (Radio Network Controller) . The 
radio network controllers handling the radio access to the user 
equipments 1 and 3 will likewise be informed on the selected 
codec using one of the above-mentioned methods as an example, 
10 and will adapt their operation mode accordingly. 

When the user equipment 3 should not support the selected codec 
indicated in the Invite message received from CSCF 2, it is 
preferably adapted to send a message to CSCF 2 informing the 

15 latter on lack of support of the selected codec. Thereupon, the 
CSCF 2 repeats the codec selection procedure 4 but now 
selecting another codec different from the first selected 
codec, "and sends this newly selected codec in a message such as 
an Invite message to user equipment 3. When this codec is 

20 supported by user equipment 3, it returns the 200 OK message, 
otherwise the above steps are repeated until a codec is 
selected which is supported by. the user equipment 3. 

Fig. 2 shows another embodiment of the invention wherein the 
25 codec selection procedure 4 is performed, similar as in the 
first embodiment- by CSCF* 2, Contrary to the abovp discussed 
first embodiment, the CSCF 2 requests, after receipt of an 
Invite message indicating all or at least some of the codecs 
supported by the user equipment 1, the user equipment 3 to 
30 return information on all codecs supported by user equipment 3. 
This message may be an Invite message of SIP defining a request 
for returning a list of supported codecs. The user e-quipment 3 
returns a message (e.g. 200 OK message of SIP) 'which contains a 
list of codecs supported by user equipment 3. 

35 
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This list may contain all codecs supported by user equipment 3, 
or may indicate only those codecs which are also supported by 
the user equipment 1. In the latter case, the user equipment 3 
receives, in the Invite message from CSCF 2, a list of the 
5 codecs supported by the user equipment 1, and is adapted to 
perform a comparison of codecs supported by user equipment 1 
and codecs supported by user equipment 3 f selecting only those 
codecs which are supported by both user equipments 1 and 3. In 
the former case in which the list returned by the user 
10 equipment 3 includes all supported codecs, the Invite message 
sent from CSCF 2 to the user equipment 3 may not contain any 
indication of codecs supported by user equipment 1. 

The CSCF 2 selects, by the codec selection procedure 4, one of 
15 the codecs supported by both user equipments 1 and 3, and then 
sends messages to both user equipments 1 and 3 informing them 
on the selected codec for use thereof during the subsequent 
connection. The message addressed to user equipment 1 may be a 
message 200 OK of SIP indicating the selected codec. The user 
20 equipment 1 may return an acknowledgement message to the CSCF 2 
acknowledging the receipt of the 200 OK message and eventually 
repeating the selected codec. The CSCF 2 may forward the 
acknowledgement message received from user equipment 1 to user 
equipment 3 after adding (if not already included) an 
25 information indicating the selected codec. 

The embodiment of Fig. 2 contributes to a very quick selection 
of a codec supported by both user equipments. 

30 All explanations, features and advantages stated above with 

regard to the first embodiment are also applicable with regard 
to this second embodiment (unless being in contradiction to the 
above explanations), and also for the subsequently discussed 
embodiments 3 and 4 . 

35 
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The embodiment shown in Fig. 3 is different from the above 
discussed first and second embodiment in that the codec 
selection procedure 4 is performed by and in the user equipment 
1. After having performed the codec selection depending on the 
5 intended application (voice transmission, non-real-time traffic 
or the like, or depending on other parameters, the user 
equipment 1 sends a message such as an Invite message to the 
user equipment 3 via the CSCF 2, indicating the selected codec. 
The user equipment 3, when supporting the selected codec, 
10 returns, via CSCF 2, an acknowledgement message which may be a 
200 OK message indicating the selected supported codec. 

In case user equipment 3 does not support the selected codec, 
the repetition of the codec selection procedure 4 including the 

15 transmission of the related messaging, is repeated, as already 
stated above with regard to the first embodiment (with the 
exception that the code selection procedure 4 is repeated in 
the user equipment 1 and not in the CSCF 2. All other 
explanations given above with regard to the first and second 

20 embodiments likewise apply to this third embodiment. 

Fig. 4 illustrates a fourth embodiment wherein the codec 
selection procedure 4 is performed in the user equipment 3. In 
this case, the user equipment 1 sends a message, via CSCF 2, to 
25 the user equipment 3 indicating all codecs supported by user 

i A r\TW Q ft +- 1 Tli-I o m/>r>r.- * s-*-^ m — > t r V-\ /^\ -mr\ Ty%ttt +- /a ty-» tT< it- —\ <~*sr\ y\ -F C T D 

After having received information on the codecs supported by 
user equipment 1, the user equipment 3 performs the codec 
selection procedure 4 by selecting, from the list of codecs 

30 supported by user equipment 1, one of the codecs which is also 
supported by user equipment 3. After having performed the codec 
selection procedure 4, the user equipment 3 sends a message to 
the user equipment 1, via the CSCF 2, informing user equipment 
1 and eventually also CSCF 2, on the selected codec. The 

35 selected codec is thereafter used by both user equipments 1 and 
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3. All other explanations given above with regard to the first 
to third embodiment likewise apply to the present fourth 
embodiment . 

5 As shown in Fig. 4 (the procedure shown in Fig. 4 is preferably 
common to all the earlier embodiments of the invention) , a 
radio access controller such as RNC 5 being in charge of radio 
access control to user eguipment 1 is informed by user 
equipment 1 on the selected codec, and preferably also on the 

10 application type by sending an application type flag indicating 
e.g. "header compression" or "header stripping/removal". This 
information can be sent when performing the PDCP negotiation 6 
but may also be sent in a separate message. In a similar 
manner, the user equipment 3 informs its radio access control 

15 element such as RNC 7 being in charge of radio access control 
to user equipment 3 by sending a message 8 to RNC 7. This 
message indicates the selected codec and may also contain, if 
known, an application type flag. 

20 This informing of the radio access control elements 5 and 7 in 
charge of the radio access to and from the user equipments 1 
and 3, respectively, is likewise applicable to all above 
described first to third embodiments in identical manner. 

25 The following embodiments of the invention relate generally to 
apparatus, and associated .method, for initiating header removal 
of packet data communicated upon a radio link a manner by which 
to facilitate initiation of header removal procedures in 
packet-switched communications effectuated by way of a radio 

30 link, such as VoIP (Voice over Internet Protocol) 
communications in a 3G (third generation) cellular 
communication system effectuated pursuant to a communication 
session. More particularly, the embodiments relate to an . 
apparatus, and an associated method, by which to generate a 

35 message selectably indicating a preference to remove the packet 
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headers preliminary to effectuation of the communication 
session. In a Quality of Service Information Element (QoS IE), 
e.g. proposed for use in a 3G GSM/EDGE (Global System for 
Mobile Communications /Enhanced Data for Global Evolution) 
5 system, a header adaptation field is defined in an available 
section, e.g. octet. Values of the bits formed in the header 
adaptation field are selected to indicate whether the header 
portions are to be removed. 

10 Generally, communication technologies permit the introduction, 
and popular usage, of new types of communication systems 
resulting, for example, in significant increases in the rates 
of data transmission. The increased data transmission rates 
allow for new types of communication services. 

15 

The embodiments of the invention, accordingly, advantageously 
provide apparatus, and associated method, by which to 
facilitate initiation of header removal procedures in packet- 
switched communications effectuated by way of a radio link, 
20 such as a VoIP (Voice over Internet Protocol) communications in 
a 3G (third generation) cellular communication system 
effectuated pursuant to a communication session. 

Through operation of an embodiment of the present invention, a 
25 message is generated indicating a preference whether to remove 
the packet headers preliminary to effectuation of the 
communication session. In a Quality of Service Information 
Element (QoS IE) proposed for use in a 3G GSM/EDGE (Global 
System for Mobile Communications/Enhanced Data for Global 
30 Evolution) system, a header adaptation field is defined in an 
available octet. Values of the bits formed in the header 
adaptation field are selected to indicate whether the header 
portions are to be removed. 
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In one aspect of the present invention, a header adaptation 
field is provided for a QoS (Quality of Service) information 
element communicated by a mobile station to the radio access 
network (RAN) portion of a radio communication system. The 
5 header adaptation field is selectably of values to initiate 
removal of the header portions of data packets to be 
communicated pursuant to a communication session, such as a 
VoIP (voice over internet protocol) communication session 
between the mobile station and another communication endpoint, 
10 such as a VoIP terminal connected to a packet data network. 

In another aspect of the invention, a manner is provided by 
which to initiate, at a mobile station operable in a packet 
radio communication system a VoIP, or other, packet-based 

15 communication session in which header information is to be 

removed from the data packets prior to their communication upon 
a radio link formed with the mobile station. Header adaptation 
indicia is sent by the mobile station to a radio access network 
portion of the communication system pursuant to session 

20 initiation. The header adaptation indicia is of values 

indicating a preference to remove the header information during 
communication of the packet data to effectuate the 
communication session. 

25 In one implementation, the header adaptation indicia is 

contained in a header adaptation field forming a portion of a 
QoS information element, formed generally pursuant to the 3GPP 
standard promulgation, section 24.008 v4 . 1 . 1 . The QoS 
information element is sent by user equipment, such as a mobile 

30 station as part of an active PDP (packet data protocol) request 
message, as part of communication session setup procedures. By 
removing the header portions of the data packets communicated 
upon a radio link during the communication with the user 
equipment, additional amounts of the limited available 
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bandwidth of the radio link is made available for use to 
effectuate communication of non-overhead information. 

A manner is thereby provided by which to initiate header 
5 removal of data packets communicated upon a radio link. Header 
removal is targeted primarily to the support of IP-based 
optimized speech in a cellular network. In order to permit a 
radio resource controller of a radio access network portion of 
the network to be able to decide whether header removal is 
10 applicable, signaling must be provided, either by a core 

network to which the radio access network portion is connected 
or by the mobile station. Operation of an embodiment of the 
present invention provides such signaling. 

15 In these and other aspects, therefore, apparatus, and 

associated method, is provided for a communication system 
having a mobile station operable to communicate packet-switched 
data with a correspondent node, by way of network 
infrastructure. The packet-switched data is formatted into data 

20 packets which have header portions and payload portions. 

Header-portion removal is initiated to facilitate communication 
of the packet-switched data upon a radio link formed between 
the mobile station and the network infrastructure. A QoS 
(Quality of Service) information element (IE) message generator 

25 is coupled to receive indications of selection of a preference 
to communicate data packets without the header portions upon 
the radio link. The QoS information element message generator 
generates a QoS information element message containing an 
indication of the preference. 

30 

A more complete appreciation of these embodiments can be 
obtained from the accompanying drawings and the following 
detailed description of the embodiments. 
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Referring first to Fig. 5, a communication system, shown 
generally as 10, provides for radio communication with a mobile 
station 12. Here, communications are effectuated pursuant to a 
communication session between the mobile station and a 
5 correspondent node 14. A communication path is formable between 
the correspondent node and the mobile station. The 
communication path is defined upon a radio link 16, elements of 
a base station system and radio access network (BSS/RAN) 
portion 18, an SGSN (Serving GPRS Service Node) 22, a GGSN 
10 (Gateway GPRS Service Node 24, and a packet data network 
backbone, here an IP (Internet Protocol) network 26. 

The radio access network portion 18 includes network elements 
operable to permit the radio connection with the mobile station 
15 upon the radio link 16. In the exemplary implementation, the 
radio access network portion is generally constructed to be 
operable pursuant to a proposed GERAN (GSM/EDGE Radio Access 
Network) , as presently promulgated. 

20 The SGSN 22 and the BSS/GERAN 18 are interfaced by an lu 

interface, analogous to a UTRAN interface. Separately, the 
radio access network portion is connectable to a 2G (second 
generation) packet switched core network by way of a Gb 
interface or, for instance, a 2G mobile switching center (MSC) 

25 by way of an A interface. 

In exemplary operation in which data originated at the mobile 
station is communicated to the correspondent node, the mobile 
station forms the sending station. And, the correspondent node 

30 which receives the data forms the receiving station. 

As two-way communications are effectuable between the mobile 
station and the correspondent node, the correspondent node also 
forms a sending station, and the mobile station also forms a 
receiving station. Description of operation of an embodiment of 

35 the present invention can analogously be described with respect 
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to communication of data by the correspondent node to the 
mobile station. 

The communication session here forms, e.g., a voice-over 
5 internet protocol (VoIP) communication session. Speech 

transmission over the packet-switched network of which the 
communication system 10 is formed is realized through the use 
of RTP (real-time transmission protocol ) -formatted packets. RTP 
packets are further encapsulated into a user data protocol 

10 (UDP) and internet protocol (IP) packets. Packet-switched 

speech transmission is generally referred to as voice-over IP 
(VoIP) . The RTP control protocol (RTCP) is defined in the RTP 
specification. RTCP is used to monitor quality of service (QoS) 
and to give information about the participants of a 

15 communication session. RTCP packets are transmitted 

periodically, less often than transmission of RTP packets to 
limit the bandwidth consumptive RTCP traffic. 

Packet-switched speech communications, such as pursuant to VoIP 
20 communications, enables an increase in the effective use of 
radio capacity, and, hence, connectivity between the mobile 
station and the correspondent node. Present proposals for the 
packet-switched speech transmission makes use of SIP/SDP for 
call control and RTP/RTCP protocols for the transmission of 
25 speech data, also in the 3G network. 

Fig. 6 illustrates the communication system 10 in logical-layer 
form, here showing the mobile station 12 and the GERAN portion 
18. The mobile station is shown to include an PDCP layer 52 

30 positioned upon an RLC layer 54. The RLC layer 54, in turn, is 
positioned upon a MAC layer 56. And, the MAC layer is 
positioned upon a lower layer, LI, 58. Analogously, the GERAN 
portion 18 includes corresponding layers, here the PDCP layer 
62, an RLC layer 64, a MAC layer 56, and a lower layer LI, 68. 

35 The radio link 16 is also shown in Fig. 6. Here, the RTP/UDP/IP 
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headers 72, here shown to be followed by a voice frame 74, is 
routed to the radio access network portion 18. The headers are 
removed at the radio access network portion. Effectively, 
through the removal of the header information, the RTP/UDP/IP 
5 protocol end-point is within the network. And, the radio access 
network 18 acts as a proxy server for the user-plane traffic 
RTP. In the control plane, i.e. r the planes 52 and 62 in Fig. 
6, SIP/SDP terminates at the mobile station 12. 



10 Fig. 7 again illustrates the mobile station 12 and the radio 
access network portion 18 in logical-layer form. The mobile 
station is shown to be formed of the layers 52, 54, 56, and 58. 
And, the radio access network portion is again shown to be 
formed of the layers 62, 64, 66, and 68. Here, a voice frame 

15 74, originated at the mobile station, is routed upon the radio 
link to the radio access network portion. Once the voice frame 
is received at the radio access network portion, the RTP/UDP/IP 
header information 72 is added to the voice frame to permit 
routing through the network to the correspondent node. 

20 

Fig. 8 illustrates a message sequence diagram, shown generally 
at 82, showing certain of the messages generated during 
operation of the communication system 10 shown in Figs. 5 to 7. 
The messages are generated pursuant to formation of a 

25 communication session between the mobile station 12, 

represented in Fig. 8 by the commonly-referenced user equipment 
block, and the correspondent node 14, indicated in Fig. 8 by 
the commonly-referenced CSCF (Call State Control Function) . The 
CSCF is an SIP proxy, and the functionality thereof is defined 

30 by 3GPP. 

First, and as indicated by the segment 84, initiation of 
communication session set up is started. SIP signaling is 
utilized to set up the session, and the mobile station/user 
35 equipment is here the entity which knows the type of 
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application which is to be used during the communication 
session . 

The message indicated by the segment 84 forms an SIP Invite 
message. The Invite message asks a callee, here the 
5 correspondent node/CSCF to join a particular conference or 
establish a two-party conversation forming a communication 
session. The Invite message typically contains a session 
description, e.g., written in SDP format, that provides the 
called party with enough information to join the session. For 

10 multicast sessions, the session description enumerates the 

media types and formats that are permitted to be distributed to 
that session. For a unicast session, the session description 
enumerates the media types and formats that the caller is 
willing to use and where the caller wishes the media data to be 

15 sent. In either case, if the callee wishes to accept the call, 
it responds to the invitation by returning a similar 
description listing the media it wishes to use. For a multicast 
session, the callee should only return a session description if 
the callee is unable to receive the media indicated in the 

20 description of the caller or if the callee wants, instead, to 
receive data via a unicast session. 

The message, indicated by the segment 8 6, is representative of 
such a response or an ACK (Acknowledge) indication returned to 

25 the mobile station. And, a final SDP message, sent by the 

mobile station/user equipment to the correspondent node/CSDF, 
is indicated by the segment 88. Additional details related to 
SIP signaling are set forth in the 3GPP ETS 23.228 and 24.2'28. 
Once both endpoints of the proposed communication session have 

30 agreed to the communication session description, the mobile 

station/user equipment activates a PDP (Packet Data Protocol) . 
An activate (secondary) PDP context request, indicated by the 
segment 92, is sent by the mobile station/user equipment to the 
SGSN 22. The request includes a QoS (quality of service) 

35 information element (IE) . When, as here, the communication 
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session is to be a VoIP communication session with optimized 
speech, i.e., with packet-data header removal, the QoS 
information element includes an indication of the preference to 
remove the RTP/UDP/IP headers from the data packets prior to 
5 their communication upon the radio link. 

Responsive to the request, the SGSN generates a radio access 
bearer assignment request, indicated by the segment 94, and 
sends the request to the BSS/RAN 18. The radio access bearer 

10 assignment request, in the exemplary implementation, 

corresponds generally in value and structure with the request 
set forth in 3GPP 25.413 and includes header adaptation field 
of an embodiment of the present invention as a portion thereof. 
The SGSN alternately can use a predefined QoS parameter 

15 combination in the radio access bearer message, thereby to 
provide unambiguous information to the GERAN that header 
removal can be utilized. 

When the BSS/GERAN receives the radio access bearer assignment 
20 message, a header adaptation mechanism algorithm at the BSS/RAN 
is used to choose a header adaptation mechanism. And, 
thereafter, the BSS/GERAN generates a radio bearer setup 
message, indicated by the segment 96, for communication upon 
the radio link to the mobile station/user equipment to inform 
25 the mobile station/user equipment of the selections made 
thereat. The BSS/RAN also generates a radio access bearer 
response, indicated by the segment 98, which is returned to the 
SGSN 22. 

30 Thereafter, and as indicated by the segment 102, an activate 
(secondary) PDP context accept message is generated by the 
SGSN. The message is sent, by way of the BSS/RAN and the radio 
link, to the mobile station/user equipment. 
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Fig. 9 illustrates a QoS information element, shown generally 
at 108, which forms a portion of the activate (secondary) PDP 
context request, identified by the segment 92 in Fig, 8. The 
QoS information element generally corresponds in format to the 
5 format set forth in the 3GPP ETS 24. 008 v4.1.1 and is 

structured to include fourteen octets. The octets are numbered 
in the Fig. as octets 1 through 14. Each octet is of an eight 
bit length. 

The first octet, octet 1, is formed of an eight-bit Quality of 
10 Service IEI field 112. The .second octet, octet 2, is formed an 
eight-bit length of quality of service IE field 114. And, the 
third octet, octet 3, is formed of a two-bit 0 spare field 116, 
a three-bit delay class field 118, and a three-bit reliability 
class field 122. 

15 

The fourth octet, octet 4, includes a four-bit peak throughput 
field 124, a single-bit spare field 126, and a three-bit 
precedence class field 128. The fifth octet, octet 5, includes 
a three-bit spare field 132 and a five-bit mean throughput 
20 field 134. The sixth octet, octet 6, includes a three-bit 

traffic class field 136, a two-bit delivery order field 138, 
and a three-bit delivery of erroneous SDU field 142. And, the 
seventh octet, octet 7, forms an eight-bit maximum SDU size 
field 144. 

25 The eighth and ninth octets, octet 8 and octet 9, also form 

single eight-bit fields. The eighth octet forms a maximum bit 
rate for uplink field 14 6, and the ninth octet forms a maximum 
bit rate for downlink field 148. 

30 The tenth octet, octet 10, forms a four-bit residual BER field 
152 and a four-bit SDU error ratio field 154. The eleventh 
octet, octet 11, forms a six-bit transfer delay field 158 and a 
two-bit traffic handling priority field 162. 
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The twelfth octet, octet 12, forms an eight-bit guaranteed bit 
rate for uplink field 164. And, the thirteenth octet, octet 13, 
forms a guaranteed bit rate for downlink field 166. 
The fourteenth octet, octet 14 forms a new octet and field 
5 pursuant to an embodiment of the present invention. The octet 
includes a six-bit spare field 168 and a two-bit header 
adaptation field 172. 

The header adaptation field is of values to identify whether 
10 header removal of the header portions of the data packets to be 
communicated upon the radio link during a communication are to 
be removed. Viz., the values of the bits which populate the 
header adaptation field indicate the preference of whether the 
header portions of the data packets are to be removed prior to 
15 their communication upon the radio link. When, as described 

above, the communication session is to be a VoIP session, the 
header portions are removed and the values of the header 
adaptation field are selected to initiate their removal. 

20 As the two-bit length of the header adaptation field permits 
four possible combinations of digital values, one of the 
digital values is a spare combination. Another combination, 
defines a no header adaptation preference. And additional 
combinations define a header removal preference and a header 

25 removal not possible indication. For instance, in the exemplary 
implementation, logical values "00" placed in the header 
adaptation field indicate a no header adaptation preference. 
Logical values of "01" placed in the header adaptation field 
indicate a header removal preference; logical values of "10" 

30 placed in the header adaptation field indicate a header removal 
not possible indication, and logical values of "11" placed in 
the header adaptation field are a spare combination. 

Thereby, a new header adaptation field formed in the QoS 
35 information element defined pursuant to proposals for set forth 
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for a 3GPP system provides a manner by which to facilitate 
selection of removal of the header portions of data packets 
prior to their communication upon a radio link. Improved 
communication capacity in the communication system is thereby 
5 possible. 

The previous descriptions are of preferred examples for 
implementing the invention, and the scope of the invention 
should not necessarily be limited by this description. The 

10 scope of the present invention also covers all modifications, 
amendments, additions and deletions of features within the 
abilities of a skilled man. As an example, the mode selection 
procedure has been described with reference to the codec 
selection but may also consist in a conversion modes selection 

15 of other type, a protocol selection procedure or the like. 
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CLAIMS 



1. Method to be performed in a communication system 
comprising at least one first network element c nnectable to a 

10 second network element via one. or more packet-based networks, 

at least one of the first and second network elements providing 
two or more selectable modes for communicating towards another 
network element, 

wherein a mode selection procedure is performed, the mode 

15 selection procedure selecting the same mode for bidirectional 
communication between the network elements, and the mode 
selected is used in both directions in the bidirectional 
communication between the first and the second network 
elements . 

20 

2. A method according to claim 1, wherein the mode 
selection procedure is performed by a network element, and the 
network element performing the mode selection procedure is one 
of the following: the first network element, the second network 

25 element, or a third network element connected to the first and 
second network elements. 



3. Method according to claim 1 or 2, wherein the 
selectable modes are different codec types. 

30 

4. Method according to claim 1, 2, or 3, wherein the 
selectable modes are radio interface protocol types. . 

5. Method according to any one of the preceding claims, 
35 wherein the modes are channel-coding schemes. 
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6. Method according to any one of the preceding claims, 
wherein the first and/or second network elements are portable 
terminal equipments . 

5 

7. Method according to any one of the preceding claims, 
wherein the third network element is a support node or support 
function. 

10 8. Method according to any one of the preceding claims, 

wherein a call control is used for sending information on 
supported or selected modes to and from the network elements. 

9. Method according to claim 8, wherein the protocol 
15 providing the call control is the Session Initiation Protocol 
(SIP) . 

10*. Method according to any one of the preceding claims, 
wherein the network or networks connecting the first and second 
20 network elements is/are a UMTS-based network. 

11. Method according to any one of the preceding claims, 
wherein the first network element is sending information on one 
or more modes supported by the first network element to the 

25 third network element which performs the selection procedure 

and sends information on only one or more than one but not all 
supported modes to the second network element which sends an 
acknowledgment message to the third network element confirming 
the support of the selected, or one of the selected modes, the 

30 third network element sending a message to the first network 
element informing the latter on the selected mode. 

12. Method according to any one of claims 1 to 10, wherein 
the first network element is sending information on one or more 

35 modes supported by the first network element to the third 
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network element which requests the second network element to 
send information on the supported modes, the second network 
element returning a list of supported modes to the third 
network element whereupon the third network element performs 
5 the selection procedure and sends messages to the first and 

second network elements informing these network elements on the 
selected mode. 

13. Method according to any one of claims 1 to 10, wherein 
10 a) the first network element performs the selection procedure 

when initiating a connection to the second network element, and 
sends information on one mode supported by the first network 
element to the second network element, 

b) the second network element, when supporting the mode, 

15 returns an acknowledgment message, or, when not supporting the 
mode, returns a message indicating another mode supported by 
the second network element, to the first network element, and 

c) the first network element selects this mode for further 
communication when supporting it, or 

20 d) when the first network element does not support the mode 

indicated by the second network element otherwise repeating the 
steps a) to d) selecting another mode. 

14. Method according to any one of claims 1 to 10, wherein 
25 the first network element, when initiating a connection to the 

second network element, sends information on all modes 
supported by the first network element to the second network 
element, 

the second network element performs the selection procedure and 
30 returns a message indicating the selected mode to the first 
network element, 

the first and second network elements selecting the indicated 
mode for further communication. 

35 15. Method according to any one of the preceding claims, 
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wherein the first network element and/or second network element 
and/or third network element is sending information on the 
selected mode to a radio network control means. 

5 16. Method according to claim 15, wherein the information 

on the selected protocol mode is sent as part of a negotiation 
procedure related to packet data convergence protocol, or in an 
Activate PDP Context message. 

10 17. Method according to claim 15 or 16, wherein the 

information on the selected mode contains an additional flag 
indicating the application type. 

18. Method according to claim 15, 16, or 17, wherein the 
15 information on the selected protocol mode contains additional 

information on the header processing such as header compression 
or header stripping/removal. 

19. Communication system comprising at least one first 
20 network element connect able to a second network element, at 

least one of the first and second network elements providing 
two or more selectable modes for communicating towards another 
network element, 

wherein the system is adapted to perform a mode selection 
25 procedure, the mode selection procedure selecting the same mode 
for bidirectional communication between the network elements, 
and the mode selected is to be used in both directions in the 
bidirectional communication between the first and the second 
network elements. 

30 

20. System according to claim 19, wherein a network 
element is adapted to perform the mode selection procedure, the 
network element performing the mode selection procedure is one 
of the following: the first network element, the second network 

35 element, or a third network element connected to the first and 
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second network elements. 

21. System according to claim 19 or 20, wherein the modes 
are different codec types or channel-coding schemes, or radio 

5 interface protocol types. 

22. System according to claim 19, 20 or 21, wherein the 
first and/or second network elements are portable terminal 
equipments. 

10 

23. System according to any one of claims 19 to 22, 
wherein the third network element is a support node or a means 
providing a support function. 

15 24. System according to any one of claims 19 to 23, 

wherein a network or networks connecting the first and second 
network elements is /are a packet-based network, preferably 
UMTS-based network. 

20 25. System according to any one of claims 19 to 24, 

wherein the first network element is adapted to send 
information on one or more protocol modes supported by the 
first network element to the third network element which is 
adapted to perform the selection procedure and to send 

25 information on only one or more than one but not all supported 
protocol modes to the second network element, the latter being 
adapted to send an acknowledgment message to the third network 
element confirming the support of the selected, or one of the 
selected protocol modes, the third network element being 

30 adapted to send a message to the first network element 
informing the latter on the selected protocol mode. 

26. System according to any one of claims 19 to 24, 
wherein the first network element is adapted to send 
35 information on one or more protocol modes supported by the 
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first network element to the third network element which is 
adapted to request the second network element to send 
information on the supported protocol modes, the second network 
element being adapted to return a list of . supported protocol 
5 modes to the third network element whereupon the third network 
element is adapted to perform the selection procedure and to 
send messages to the first and second network elements 
informing these network elements on the selected protocol mode. 

10 27. System according to any one of claims 19 to 24, 

wherein 

a) the first network element is adapted to perform the 
selection procedure when initiating a connection to the second 
network element, and to send information on one mode supported 

15 by the first network element to the second network element, 

b) the second network element being adapted to return, when 
supporting the mode, an acknowledgment message, or, when not 
supporting the mode, to return a message indicating another 
mode supported by the second network element, to the first 

20 network element, and 

c) the first network element being adapted to select this mode 
for further communication when supporting it, or, 

d) when the first network element does not support the mode 
indicated by the second network element, the system being 

25 adapted to repeat the steps a) to d) selecting another mode. 

28. System according to any one of claims 19 to 24, 
wherein 

a) the first network element is adapted to send, when 
30 initiating a connection to the second network element, 

information on all modes supported by the first network element 
to the second network element, 

b) the second network element being adapted to perform the 
selection procedure and to return a message indicating the 

35 selected mode to the first network element, 
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the first and second network elements being adapted to use the 
indicated mode for further communication. 

29. System according to any one of claims 19 to 28, 

5 wherein the system is adapted to use a call control protocol 
for sending information on supported or selected modes to and 
from the network elements. 

30. System according to claim 29, wherein the protocol is 
10 the Session Initiating Protocol (SIP) . 

31. System according to any one of claims 19 to 30, 
wherein the first network element and/or second network element 
and/or third network element is adapted to send information on 

15 the selected mode to a radio network control means. 

32. System according to claim 31, being adapted to send 
the information on the selected mode as part of a negotiation 
procedure related to packet data convergence protocol, or in an 

20 Activate PDP Context message. 

33. System according to claim 31 or 32, wherein the 
information on the selected mode contains an additional flag 
indicating the application type. 

25 

34. System according to claim 31, 32, or 33, wherein the 
information on the selected mode contains additional 
information on the header processing such as header compression 
or header stripping/removal. 

30 

35. Network element, preferably to be used in a method as 
defined in any one of the claims 1 to 18, or in a communication 
system as defined in any one of claims 19 to 34, the network 
element being adapted to perform a selection procedure for 

35 selecting one of several modes supported by this or another 
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network element. 

36. Network element according to claim 35, wherein the 
modes are different conversion modes, in particular 

5 coding/decoding modes. 

37. Apparatus for initiation of header-portion removal in 
a radio communication system having a mobile station operable 
to communicate packet-switched data with a correspondent node 

10 by way of network infrastructure, the packet-switched data 
formatted into data packets, the data packets having header 
portions and payload portions, the header-portion removal 
facilitating communication of the packet-switched data upon a 
radio link formed between the mobile station and the network 

15 infrastructure, said apparatus comprising: 

a QoS (Quality of Service) information element (IE) message 
generator coupled to receive indications of selection of a 
preference to communicate data without the header portions upon 
the radio link, said QoS information element message generator 

20 for generating a QoS information element message containing an 
indication of the preference. 

38. The apparatus of claim 37, wherein said QoS 
information element message generator is positioned at the 

25 mobile station. 

39. The apparatus of claim 37, wherein the QoS information 
element defines a plurality of fields and wherein the 
indication of the preference is contained in a selected field 

30 of the plurality of fields. 

40. The apparatus of claim 39, wherein the radio 
communication system comprises a 3G (third generation) cellular 
communication system, wherein the correspondent node comprises 

35 a VoIP (Voice over Internet Protocol) terminal and the packet- 
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switched data comprises VoIP data for effectuating a VoIP 
communication session, and wherein the QoS information element 
message generated by said QoS information element message 
generator is generated prior to the VoIP communication session. 

5 

41. The apparatus of claim 40, wherein the QoS information 
element message generated by said QoS information message is 
defined generally preferably pursuant to a 3GPP ETS, Section 
24*008 v4.1.1 promulgation, and wherein the indication of the 

10 preference contained in the selected field is contained in a 
field appended to, and forming a portion of, the message. 

42. The apparatus of claim 41, wherein the QoS information 
message element includes a header adaptation field and wherein 

15 the indication of the preference is contained in the header 
adaptation field. 



43. The apparatus of claim 42, wherein the QoS information 
element message comprises a plurality of octets and wherein the 

20 header adaptation field is formed in a final octet of the QoS 
information element message. 

44. The apparatus of claim 4 3, wherein the QoS information 
element comprises fourteen octets and wherein the header 

25 adaptation field is contained in the fourteenth octet of the 
QoS information element. 



45. The apparatus of claim 42, 43, or 44, wherein the 
header adaptation field is of a two-bit length. 

30 

4 6. Method for initiation of header-portion removal in a 
method for communicating in a radio communication system having 
a mobile station operable to communicate packet-switched data 
with a correspondent node by way of network infrastructure, the 
35 packet-switched data formatted into data packets, the data 



42 



WO 02/15627 



PCT7EP01/09292 



packets having header portions and payload portions, the 
header-portion removal facilitating communication of the 
packet-switched data upon a radio link formed between the 
mobile station and the network infrastructure, said method 
5 comprising: 

selecting a preference whether to communicate data packets 
without the header portions on the radio link; and 
generating a QoS information element message containing an 
indication of the preference. 

10 

47. The method of claim 4 6, wherein said operations of 
selecting and generating .are performed at the mobile station, 
said method further comprising the operation of sending the QoS 
information element message upon the radio link. 



RNSnomn- <WO 021 5627 A 1 I > 



43 



WO 02/15627 



1/8 



PCT/EP01/09292 



7 



o 

O 
O 

o 

CO 

<D 
*> 

c 



o 

CD 

o 
o 

*0 
CD 

-»--» 
O 

JD 

CO 

O 
o 

CM 




CO 

O 
<D 

o 
o 

-a 
a> 

t: 
o 

Q- 
Cu 

^co^ 

• T-H 

> 





o 
cd 

no 
O 
O 

*a 

CD 
» 

O 
JD 

13 

CO 

o 

O 

o 



WO 02/15627 



2/8 



PCT/EP01/09292 













Id 




O 



7 




CM 



BNSOOCID: <WO 0215627A1_I_> 



WO 02/15627 



3/8 



PCT/EP01/09292 














Id 


O 



CO 

ri> 
iZ 



«MRnnrw> <wn 02i5627Ai i > 



WO 02/15627 PCT/EP01/09292 

4/8 

















O 






LL. 



o 

o 

Q 

fx, 



O 
O 

o 

<D 
O 

CO 



H 

CL, 

< IX. 



WO 02/15627 



5/8 



PCT/EP01/09292 




WO 02/15627 



6/8 



PCT/EP01/09292 



10 



74 ^-72 ^74 





VOICE FRAME 




RTP/UDP/IP 


VOICE FRAME 




+ 




I 1 




52- 


PDCP 




PDCP 


-—-62 


54- 


RLC 


^74 




RLC 


— -64 


56- 


MAC 




MAC 


-—66 


VOICE FRAME 




58- 


L1 




L1 


—-68 



MS S ~ " S GERAN 



FIG. 6 





^74 




VOICE FRAME 






52- 


PDCP 


54- 


RLC 


56- 


MAC 


58- 


L1 




MS ^ 



12 



16 



.74 



72 



RTP/UDP/IP 



VOICE FRAME 



GERAN ^ 
18 



-74 



VOICE FRAME 



PDCP 


——62 


RLC 


-—64 


MAC 


---66 


L1 


-—68 



FIG. 7 



> 0215627A1_L> 



WO 02/15627 PCT/EPO 1/09292 

7/8 



12 



£L 

M/STN 
UE 



18 



RAN 




SGSN 




CSCP 



INVITE 



SIP SIGNALLING 



FINAL SDP 



ACTIVATE (SECONDARY) 
PDP CONTEXT REQUEST 



84 



86 



88 



92 



RADIO ACCESS 
BEARER . 



RADIO BEARER. 



96 



102 



SETUP 

98 

ACTIVATE 



REQUEST 

RADIO ACCESS 
BEARER , 



RESPONSE 
(SECONDARY) 



PDP CONTEXT ACCEPT 



-94 



14 



SDP 



FIG. 8 



DMcrwm- .-wo 



WO 02/15627 



PCT/EP01/09292 



8/8 
108 



8 



112 
114 

116 
124 
132 

136 

144 
146 
148 
152 

158 

164 
166 
168 



QUALITY OF SERVICE IEI 


LENGTH OF QUALITY OF SERVICE IE 


0 
0 

SPARE 


DELAY 118 
CLASS — 


RELIABILITY 
CLASS 


PEAK 
THROUGHPUT 


0 

SPARE 


PRECEDENCE 
CLASS 


0 o 

0 

SPARE 


MEAN 
THROUGHPUT 


TRAFFIC CLASS 


DELIVERY ORDER 
138 


DELIVERY OF 
ERRONEOUS SDU 


MAXIMUM SDU SIZE 


MAXIMUM BIT RATE FOR UPLINK 


MAXIMUM BIT RATE FOR DOWNLINK 


RESIDUAL BER 


SDU ERROR RATIO 


TRANSFER DELAY 


TRAFFIC HANDLING 
PRIORITY 


GUARANTEED BIT RATE FOR UPLINK 


GUARANTEED BIT RATE FOR DOWNLINK 


SPARE 


HEADER 
ADAPTATION 



OCTET 1 

OCTET 2 
OCTET 3 

122 

OCTET 4 

128 

OCTET 5 

134 

OCTET 6 

142 

OCTET 7 

OCTET 8 

OCTET 9 

OCTET 10 
^154 
OCTET 11 

162 

OCTET 12 

OCTET 13 
OCTET 14 

172 



FIG. 9 



INTERNATIONAL SEARCH REPORT 



Inte: al Application No 

PC . • 01/09292 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 H04Q7/38 H04L29/06 






According to International Patent Classification (IPC) or to both national classification and IPC 




B. FIELDS SEARCHED 


Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 H04Q H04L 


Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 


Electronic data base consulted during the international search (name of data baa 


eand, where practical, search terms used) 


EPO-Internal 






C* DOCUMENTS CONSIDERED TO BE RELEVANT 


Category • 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


X 


US 5 924 026 A (KRISHNAN ARJUN) 




1,2,4, 




13 July 1999 (1999-07-13) 




6-8,13, 






14, 

19-23, 
27-29, 
35,36 




column 3, line 44 -column 4, line 


34 






column 5, line 30 -column 8, line 


64 






column 13, line 49 - line 58 








column 14, line 28 -column 15, line 15 






figures 2,4A,4B 






X 


WO 97 48212 A (NOKIA TELECOMMUNICATIONS 0Y 


1-3, 




;KARI HAMNU H (FD) 




19-21, 




18 December 1997 (1997-12-18) 




35,36 


A 


page 2 5 line 28 -page 3, line 19 
page 4, line 22 -page 5, line 4 
figure 1 


/— 


37,46 


| )(j Further documents are listed in the continuation of box C. 


j)( | Palenl family members are listed in annex 


° Special categories of cited documents : 

■A' document defining the general state of the art which is not 
considered to be of particular relevance 


T* later document published after the international filing date 
or priority date and not in conflict wilh the application but 
cited to understand the principle or theory underlying the 
invention 


•E' earlier document but published on or after the international - x . document of particular relevance; the claimed invention 
rmng date cannot be considered novel or cannot be considered to 

•L" document which may throw doubts on priority daim(s) or involve an inventive step when the document is taken alone 
which Is cited to establish the publication date of another ■y p document of particular relevance; the claimed invention 
citation or other special reason (as specified) be considered to involve an inventive step when the 

"O" document referring to an oral disclosure, use, exhibition or document is combined with one or more other such docu- 
other means ments, such combination being obvious to a person skilled 


•p" document published prior lo the international fifing date but 
! later than the priority date claimed 


in me art 

document member of the same patent family 


Date of lhe actual completion of the international search 


Dale of mailing of the international search report 


29 October 2001 


07/11/2001 




Name and mailing address of the ISA 


Authorized officer 






European Palent Office, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswqk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 


Barel , C 





Form PCT/ISA/210 (second sheet) (July 1992) 



INTERNATIONAL SEARCH REPORT 


tntet 

PC 


at Application No 

» 01/09292 


C.(ContinuaUon) DOCUMENTS CONSIDERED TO BE RELEVANT 


Category • 


Citation of document, with indication .where appropriate, of the relevant passages 


Relevant to claim No. 


X 
A 


WO 99 12329 A (DUTNALL STEPHEN ; BRITISH 
TELECOMM (GB)) 11 March 1999 (1999-03-11) 
column 6, line 14 - line 30 
page 14, line 31 -page 15, line 20 
page 16, line 3 -page 17, line 34 
figures 6-10 






37,46 
40 


P,X 


WO 01 08434 A (GROVES CHRISTIAN NORMAN 
;RYTINA IAN (AU); GRAF LESLIE GARY (AU); 
H) 1 February 2001 (2001-02-01) 

page 1, line 19 - line 29 
page 2, line 21 -page 9, line 32 
figures 1,2 






1-3,6-8, 

10-12, 

15, 

19-26, 
29,35,36 



Form PCT /ISA/210 (continuation ol second sheel) (July 1992) 



INTERNATIONAL SEARCH REPORT 



Intei il Application No 

PC ' 01/09292 



Patent document 
cited In search report 



Publication 
date 



Patent family 
member(s) 



Publication 
date 



US 5924026 



13-07-1999 NONE 



WO 9748212 


A 


18-12- 


-1997 


FI 


962381 A 


08-12-1997 










AU 


2965697 A 


07-01-1998 










EP 


0898825 Al 


03-03-1999 










WO 


9748212 Al 


18-12-1997 










JP 


2000513519 T 


10-10-2000 


WO 9912329 


A 


11-03- 


-1999 


AU 


8741498 A 


22-03-1999 










CN 


1269940 T 


11-10-2000 










EP 


1010314 Al 


21-06-2000 










WO 


9912329 Al 


11-03-1999 










OP 


2001515314 T 


18-09-2001 



WO 0108434 A 01-02-2001 W0 0108434 Al 01-02-2001 

AU 5953700 A 13-02-2001 



Four PCT/ISA/S10 (patent lamily annex) (July 1992) 



